le hack

Trouvé
J’espère être capable d’être clair
Donc pour que l’album lance l’album le vrai
Il faut copier le fichier override_config.ini trouvable dans le dossier atmosphère, sous dossier config_templates. Ce dossier demande un 1er lancement de atmosphére pour être créé si hack fraîchement effectué
Une fois fait, il faut coller ce fichier dans atmosphère/config.
Éditer ce fichier depuis ce dossier via bloc note:
Dans [hbl_config]
; override_key_O=!R
Cette ligne est celle en question elle doit être :
override_key_O=R
Donc supprimer les ponctuations et enregistrer le fichier
Une fois fait, lancer l’album depuis atmosphère lancera les captures et vidéos, pour accéder au hbl il faudra maintenir r comme à l’époque des 1eres versions d’atmosphère

@MDproz
tu penses qu'une update de ces jeux pourrait régler le pb?
comme indiqué, c'est une version 16.0.3 sur laquelle j'ai dumpé les prod keys depuis cette version avec picklock que j'avais de coté
alors que l'autre est hack depuis longtemps maintenant, c'est la seule diff entre les 2
et comme tu dis pas de raison..
c'est pour cela que je demande de l'aide au meilleur

Le jeu demande HOS 16.0.2.
La console peut être mise à jour en 16.0.2 ou 16.0.3 pour sysNAND et emuNAND. Rien n’empêche l’autre puisque le hack est opérationnel pour le dernier firmware. Pourquoi mettre à jour un et pas l’autre, c’est un élément qui m’échappe et qui appartient à chacun.

En sysNAND et/ou emuNAND, la seule chose qui pourrait provoquer cela est lorsque la console, en mode hack, a le patch NOGC actif.

Aucun tutoriel ne traite des sujets concernant les dongle. Ton RCM Loader possède un site auquel un suivi est assuré mais aucun lien ne peut être donné. Et effectivement, ton Dongle a des mises à jour disponibles.

La couleur des Leds correspond à cela:


Pour le reste de la procédure, le rôle de ton dongle, c'est d'injecter le payload. A savoir, le bin qui correspond au hack que tu vas utiliser et comment tu vas booter. En fonction de ton choix, il te faudra préparer ta SD avec tous les éléments nécessaires car cela ne change pas que tu utilises un dongle ou non. Cette préparation s'opère via SDSetup ou manuellement.

Si tu veux utiliser Atmosphère par exemple, tu mets le payload.bin dans le dossier ATMOSPHERE_HEKATE sur le dongle. Et de même pour Hekate.

Pour voir quel payload est injecté sur le dongle:

1. Tu appuies une fois sur le bouton + du dongle
2. Ça clignote à la couleur du payload en attente d’injection
3. Si tu veux changer de payload, tu restes appuyer sur +

NB: il changera la couleur

Si on part sur une utilisation du dongle :

1. Tu vérifies la mise à jour du Dongle si besoin
2. Tu prépares ta SD via SDSetup préalablement avec les dernières versions des outils et du CFW où tu le fais manuellement si le site ne propose pas les dernières mises à niveau

NB: Ne pas oublier d’ajouter les sigpatches manuellement

3. Tu prends l'ensemble des éléments qui concernent les dossiers et payload.bin présents dans les dossiers de ta mise à jour pour le Dongle
4. Tu ne modifies pas leurs noms
5. Tu les copies/colles sur le dongle

NB: Supprime les anciens éléments et fichier qui s’y trouvent ou fait un écrasement

6. Tu changes la couleur en bleu Atmosphère

NB: la SD est préalablement préparée pour avoir l’ensemble des éléments

7. Tu lances le mode RCM avec le JIG
8. Tu bootes avec le Dongle inséré
9. Le hack se lance
10. Enjoy !

Sauf erreur, cela doit se passer ainsi mais à vérifier ! Il existe des infos sur ton RCM Loader sur la toile pour t’en assurer !

Toutes les questions posées depuis ont leur réponse dans la FAQ qu’il faut lire pour comprendre un peu mieux car là je vais résumer grossièrement !

Le hack n’est pas permanent et si tu redémarres ta console, tu te rends bien compte que rien n’est installé sauf les fichiers NSP (qui eux ne fonctionneront pas puisque le hack n’est pas actif). Le fait d’injecter un payload permet de loader et cela depuis ta SD et non depuis la console. Pour Hekate qui est un custom bootloader, c’est ainsi (et pour d’autres également).

En revanche, en fonction de ce que tu utilises, cela laisse des traces dans la télémétrie d’où le fait de ne pas utiliser sa sysNAND pour les aspects underground et de créer une emuNAND. Les deux sont déliées.

Pour Hekate, il utilise un bootloader personnalisé qui n’est pas celui de Nintendo d’où le fait de ne pas aller sur le online. Il possède trois mode de boot qui utilisent son bootloader donc la connexion est à éviter. En démarrant la console normalement, elle utilise le bootloader de Nintendo. Le hack n’est plus actif.

Rien est installé lorsqu’il s’agit d’utiliser un payload (fichier bin) qui se charge de loader depuis la SD et non depuis la console.

Comme dit plus haut, ce qui modifie la NAND, c’est l’installation de NSP, certains homebrews comme RetroArch, le mode autoRCM car il se charge de corrompre la boot et autres.
La sysNAND, c’est la NAND système de la console et l’emuNAND, c’est la NAND système sur la SD. Donc pour éviter de modifier la NAND système de la console avec l’underground, on crée et on utilise une emuNAND.